Network agent for reporting to a network policy system

ABSTRACT

The disclosed technology relates to a network agent for reporting to a network policy system. A network agent includes an agent enforcer and an agent controller. The agent enforcer is configured to implementing network policies on the system, access data associated with the implementation of the network policies on the system, and transmit, via an interprocess communication, the data to the agent controller. The agent controller is configured to generate a report including the data and transmit the report to a network policy system.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a Continuation of U.S. patent application Ser. No.16/999,447, filed on Aug. 21, 2020, which in turn, is a Continuation ofU.S. patent application Ser. No. 15/469,737, filed Mar. 27, 2017, nowU.S. Pat. No. 10,764,141 the contents of which are incorporated hereinby reference in their entirety.

TECHNICAL FIELD

The subject matter of this disclosure relates in general to the field ofcomputer networks, and more specifically for management of entities andresources within a computer network.

BACKGROUND

A managed network, such as an enterprise private network (EPN), maycontain a large number of entities distributed across the network. Theseentities include, for example, nodes, endpoints, machines, virtualmachines, containers (an instance of container-based virtualization),and applications. In addition to being different types, these entitiesmay be grouped in different departments, located in differentgeographical locations, and/or serve different functions.

An expansive or thorough understanding of the network can be criticalfor network management tasks such as anomaly detection (e.g., networkattacks and misconfiguration), network security (e.g., preventingnetwork breaches and reducing network vulnerabilities), asset management(e.g., monitoring, capacity planning, consolidation, migration, andcontinuity planning), and compliance (e.g. conformance with governmentalregulations, industry standards, and corporate policies). Traditionalapproaches for managing large networks require comprehensive knowledgeon the part of highly specialized human operators because of thecomplexities of the interrelationships among the entities.

BRIEF DESCRIPTION OF THE FIGURES

In order to describe the manner in which the above-recited and otheradvantages and features of the disclosure can be obtained, a moreparticular description of the principles briefly described above will berendered by reference to specific embodiments that are illustrated inthe appended drawings. Understanding that these drawings depict onlyembodiments of the disclosure and are not therefore to be considered tobe limiting of its scope, the principles herein are described andexplained with additional specificity and detail through the use of theaccompanying drawings in which:

FIG. 1 is a conceptual block diagram illustrating an example of anintent driven network policy platform, in accordance with variousembodiments of the subject technology;

FIG. 2 is an illustration showing contents of an inventory store, inaccordance with various embodiments of the subject technology;

FIG. 3 illustrates two examples of inventory filters, in accordance withvarious embodiments of the subject technology;

FIG. 4 illustrates an example flow filter incorporating two inventoryfilters, in accordance with various embodiments of the subjecttechnology;

FIG. 5 shows an example process for managing a network using user intentstatements, in accordance with various embodiments of the subjecttechnology;

FIG. 6 is a conceptual block diagram illustrating an example of anetwork entity that includes a network agent, in accordance with variousembodiments of the subject technology;

FIG. 7 shows an example process for implementing network policies on anetwork entity, in accordance with various embodiments of the subjecttechnology;

FIG. 8 shows an example process for providing network entity reports toa network policy system, in accordance with various embodiments of thesubject technology; and

FIGS. 9A and 9B illustrate examples of systems in accordance with someembodiments.

DESCRIPTION OF EXAMPLE EMBODIMENTS

The detailed description set forth below is intended as a description ofvarious configurations of embodiments and is not intended to representthe only configurations in which the subject matter of this disclosurecan be practiced. The appended drawings are incorporated herein andconstitute a part of the detailed description. The detailed descriptionincludes specific details for the purpose of providing a more thoroughunderstanding of the subject matter of this disclosure. However, it willbe clear and apparent that the subject matter of this disclosure is notlimited to the specific details set forth herein and may be practicedwithout these details. In some instances, structures and components areshown in block diagram form in order to avoid obscuring the concepts ofthe subject matter of this disclosure.

Overview

Large networks often require comprehensive knowledge on the part ofhighly specialized human operators (e.g., network administrators) toeffectively manage. However, controls available to the human operatorsare not very flexible and the human operators with the specializedknowledge able to manage the network(s) are often not the individualswith a higher level understanding of how the network should operate withrespect to certain applications or functionalities. Furthermore, once achange in network management is executed, it is often difficult to rollback the changes, make alterations, or understand the changes, even fornetwork operators.

The disclosed technology addresses the need in the art for a moreintuitive way to manage a network and a way to manage the network in amore targeted manner. For example, many networks may be secured usingaccess control lists (ACLs) implemented by routers and switches topermit and restrict data flow within the network. When an ACL isconfigured on an interface, the network device examines data packetspassing through the interface to determine whether to forward or dropthe packet based on the criteria specified within the ACLs. Each ACLincludes entries where each entry includes a destination target internetprotocol (IP) address, a source target IP address, and a statement ofpermission or denial for that entry.

The ACLs, however, may be difficult for application developers and otherusers with limited knowledge of network engineering to understand anduse. A development team that builds a particular application, set ofapplications, or function(s) (e.g., an “application owner”) is typicallynot responsible for managing an enterprise network and are not expectedto have a deep understanding of the network. The application ownerunderstands at a high level how certain applications or functions shouldoperate, which entities should be allowed or restricted fromcommunicating with other entities, and how entities should be allowed orrestricted from communicating with other entities (e.g., which portsand/or communication protocols are allowed or restricted). In order toimplement desired network policies, the application owner must contact anetwork operator and communicate their objectives to the networkoperator. The network operator tries to understand the objectives andthen creates ACL entries that satisfy the application owner'sobjectives.

Even relatively simple network policies take hundreds, thousands, ormore ACL entries to implement and ACLs often end up containing millionsof entries. For example, to implement a simple network rule where afirst subnet of machines cannot communicate with a second subnet ofmachines requires 2(m×n) ACL entries for a number of m endpoints in thefirst subnet and a number of n endpoints in the second subnet toexplicitly list out each IP address in the first subnet that cannot senddata to each IP address in the second subnet and each IP address in thesecond subnet cannot send data to each IP address in the first subnet.The size of the ACLs can further complicate matters making intelligentlyaltering the ACLs increasingly difficult. For example, if an applicationowner wants to alter the implemented network policies, it is difficultfor the application owner or the network operator to know which ACLentries were created based on the original network policy and, as aresult, difficult to identify ACL entries to add, delete, or modifybased on the alteration of the network policies.

Furthermore, traditional ACLs permit and restrict data flow within thenetwork at the machine level. For example, ACL entries permit orrestrict communication based on a destination target internet protocol(IP) address and a source target IP address. However, in some cases,applications on one network entity (e.g., a physical server, virtualmachine, container, etc.) should be able to communicate with otherapplications on a different network entity, but other communicationsbetween the entities should be restricted for security reasons (e.g.,some hackers may take advantage of broad traditional ACL entries and useapplications to gain access to other areas of the network). TraditionalACL entries are unable to accommodate for more tailored control ofnetwork traffic.

Various embodiments of the subject technology address these and othertechnical problems by providing an intent driven network policy platformthat allows both application owner and network operators to definenetwork policies in a more understandable manner and provides theseusers with finer levels of controls.

DETAILED DESCRIPTION

Various embodiments of the disclosure are discussed in detail below.While specific implementations are discussed, it should be understoodthat this is done for illustrative purposes only. A person skilled inthe relevant art will recognize that other components and configurationsmay be used without departing from the spirit and scope of thedisclosure.

Various embodiments relate to an intent driven network policy platformconfigured to ingest network data and generate an inventory of networkentities. The network policy platform receives a user intent statement,translates the intent into network policies, and enforces the networkpolicies.

FIG. 1 is a conceptual block diagram illustrating an example networkenvironment 100 that includes an intent driven network policy platform110, in accordance with various embodiments of the subject technology.Various embodiments are discussed with respect to an enterprise privatenetwork (EPN) for illustrative purposes. However, these embodiments andothers may be applied to other types of networks. For example, thenetwork environment 100 may be implemented by any type of network andmay include, for example, any one or more of a cellular network, asatellite network, a personal area network (PAN), a local area network(LAN), a wide area network (WAN), a broadband network (BBN), theInternet, and the like. The network environment 100 can be a publicnetwork, a private network, or a combination thereof. The networkenvironment 100 may be implemented using any number of communicationslinks associated with one or more service providers, including one ormore wired communication links, one or more wireless communicationlinks, or any combination thereof. Additionally, the network environment100 can be configured to support the transmission of data formattedusing any number of protocols.

The network environment 100 includes one or more network agents 105configured to communicate with an intent driven network policy platform110 via enforcement front end modules (EFEs) 115. The intent drivennetwork policy platform 110 is shown with one or more EFEs 115, a userinterface module 120, a coordinator module 125, an intent service module130, an inventory store 150, and a policy store 155. In otherembodiments, the intent driven network policy platform 110 may includeadditional components, fewer components, or alternative components. Thenetwork policy platform 110 may be implemented as a single machine ordistributed across a number of machines in the network.

Each network agent 105 may be installed on a network entity andconfigured to receive network policies (e.g., enforcement policies,configuration policies, etc.) from the network policy platform 110 viathe enforcement front end modules 115. After an initial installation ona network entity (e.g., a machine, virtual machine, or container, etc.),a network agent 105 can register with the network policy platform 110and communicate with one or more EFEs to receive network policies thatare configured to be applied to the host on which the network agent 105is running. In some embodiments, the network policies may be received ina high-level, platform independent format. The network agent 105 mayconvert the high-level network policies into platform specific policiesand apply any number of optimizations before applying the networkpolicies to the host network entity. In some embodiments, the high-levelnetwork policies may be converted at the network policy platform 110.

Each network agent 105 may further be configured to observe and collectdata and report the collected data to the intent driven network policyplatform 110 via the EFEs 115. The network agent 105 may collect policyenforcement related data associated with the host entity such as anumber of policies being enforced, a number of rules being enforced, anumber of data packets being allowed, dropped, forwarded, redirected, orcopied, or any other data related to the enforcement of networkpolicies. The network agent 105 may also collect data related to hostentity performance such as CPU usage, memory usage, a number of TCPconnections, a number of failed connection, etc. The network agent 105may also collect other data related to the host such as an entity name,operating system, entity interface information, file system information,applications or processes installed or running, or disks that aremounted.

The enforcement front end modules (EFEs) 115 are configured to handlethe registration of the network agents 105 with the network policyplatform 110, receive collected data from the network agents 105, andstore the collected data in inventory store 150. The EFEs may be furtherconfigured to store network policies (high-level platform independentpolicies or platform specific policies) in memory, periodically scan apolicy store 155 for updates to network policies, and notify and updatenetwork agents 105 with respect to changes in the network policies.

The user interface 120 receives input from users of the network policyplatform 110. For example, the user interface 120 may be configured toreceive user configured data for entities in the network from a networkoperator. The user configured data may include IP addresses, host names,geographic locations, departments, functions, a VPN routing/forwarding(VRF) table, or other data for entities in the network. The userinterface 120 may be configured to collect the user configured data andstore the data in the inventory store 150.

The user interface 120 may also be configured to receive one or moreuser intent statements. The user intent statements may be received froma network operator, application owner, or other administrator or throughanother entity via an application programming interface (API). A userintent statement is a high-level expression of one or more network rulesthat may be translated into a network policy.

The user interface 120 may pass a received user intent statement to theintent service 130 where the intent service 130 is configured to formatthe user intent statements and transform the user intent statement intonetwork policies that may be applied to entities in the network.According to some embodiments, the intent service 130 may be configuredto store the user intent statements, either in formatted ornon-formatted form, in an intent store. After the user intent statementsare translated into network policies, the intent service 130 may storethe network policies in policy store 155. The policy store 155 isconfigured to store network policies. The network policies may behigh-level platform independent network policies or platform specificpolicies. In some embodiments, the policy store 155 is implemented as aNoSQL database.

The intent service 130 may also track changes to intent statements andmake sure the network policies in the policy store are up-to-date withthe intent statements in the intent store. For example, if a user intentstatement in the intent store is deleted or changed, the intent service130 may be configured to located network policies associated with thedeleted user intent statement and delete or update the network policiesas appropriate.

The coordinator module 125 is configured to assign network agents 105 toEFEs. For example, the coordinator 125 may use a sharding technique tobalance load and improve efficiency of the network policy platform 110.The coordinator 125 may also be configured to determine if an update tothe policy store is needed and update the policy store accordingly. Thecoordinator 125 may further be configured to receive data periodicallyfrom the network agents 105 via the EFEs 115, store the data in theinventory store 150, and update the inventory store 150 if necessary.

FIG. 2 is an illustration showing contents of an inventory store 200, inaccordance with various embodiments of the subject technology. Theinventory store 200 is configured to contain data and attributes foreach network entity managed by the intent driven network policy platform110. The network entities may include machines (e.g., servers, personalcomputers, laptops), virtual machines, containers, mobile devices (e.g.,tablets or smart phones), smart devices (e.g., set top boxes, smartappliances, smart televisions, internet-of-things devices), or networkequipment, among other computing devices. Although the inventory store200 is implemented as a conventional relational database in thisexample, other embodiments may utilize other types of databases (e.g.,NoSQL, NewSQL, etc.).

The inventory store 200 may receive user configured data from the userinterface 120 and data received from the network agents 105 via the EFEs115 and store the data in records or entries associated with networkentities managed by the network policy platform 110. Each record in theinventory store 200 may include attribute data for a network entity suchas one or more entity identifiers (e.g., a host name, IP address, MACaddresses, hash value, etc.), a geographic location, an operatingsystem, a department, interface data, functionality, a list of one ormore annotations, file system information, disk mount information,top-of-rack (ToR) location, and a scope.

In some embodiments, the inventory store 200 may also include entityperformance and network enforcement data either together with theattribute data or separately in one or more separate data stores. Theperformance and network enforcement data may include CPU usage, memoryusage, a number of TCP connections, a number of failed connections, anumber of network policies, or a number of data packets that have beenallowed, dropped, forwarded, or redirected. The inventory store 200 mayinclude historical performance or enforcement data associated withnetwork entities or metrics calculated based on historical data.

A user intent statement is a high-level expression of that may betranslated into one or more network policies. A user intent statementmay be composed of one or more filters and at least one action. Thefilters may include inventory filters that identify network entities onwhich the action is to be applied and flow filters that identify networkdata flows on which the action is to be applied.

For example, if a user wished to identify all network entities locatedin Mountain View, Calif. (abbreviated MTV in the location column of theinventory store), the inventory filter “Location==MTV” may be used. If auser wished to identify all network entities located in a ResearchTriangle Park facility in North Carolina (abbreviated RTP in thelocation column of the inventory store), the inventory filter“Location==RTP” may be used. Inventory filters may also identifyrelationships between two or more sets of entities (e.g., a union orintersection of sets). For example, if a user wished to identify allnetwork entities located in Mountain View, Calif. and running Windows 8operating system, the inventory filter “Location==MTV and OS==Windows8”may be used.

A flow filter identifies network data flows. For example, if a userwished to identify all data flows from network entities in Mountain Viewto network entities in the Research Triangle Park facility, thefollowing flow filter may be used:

-   -   Source: Location==MTV    -   Destination: Location==RTP

Each filter may further be defined beforehand and assigned a name formore convenient use. For example, the inventory filter “Location==MTV”may be assigned the name “MTV_entities” and the inventory filter“Location==RTP” may be assigned the name “RTP_entities.” As a result, auser may use the following to achieve the same result as the aboveexample flow filter:

-   -   Source: MTV_entities    -   Destination: RTP_entities

Different actions may be applied to different filters. For example,actions applicable to inventory filters may include annotation andconfiguration actions. Annotating actions adds tags or labels to networkitems in the inventory store or flow data. Annotations may help networkoperators identify network entities. Configuration actions may be usedto configure network entities. For example, some configuration actionsmay be used to set a CPU quota for certain applications, processes, orvirtual machines. Other configuration actions may enable or disablemonitoring of certain metrics, collection and transmittal of certaindata, or enforcement of certain network policies. Some configurationactions may also be able to enable or disable certain modes within anetwork entity. For example, some entities may be configured to run in a“high visibility mode” in which most metrics and data (e.g., full timeseries data) are collected and transmitted to the network policyplatform for analysis or in “low visibility mode” in which only a smallsubset of the available metrics and data are collected and transmitted.Some configuration actions are able to enable or disable these modes.

Actions applicable to flow filters may include annotation or networkenforcement actions. Network enforcement actions include, for example,allowing data packets, dropping data packets, copying data packets,redirecting data packets, encrypting data packets, or load balanceacross network entities.

Using the above examples, a user that wishes to drop all data flowingfrom entities in Mountain View to entities in Research Triangle Park mayuse the following user intent statement:

-   -   Source: MTV_entities    -   Destination: RTP_entities    -   Action: Drop

User intent statements may further specify types of communications orcommunication protocols used, ports used, or use any other filter toidentify a network entity or network flow on which to apply an action.For example, if the user only wishes to drop transmission controlprotocol (TCP) communications out of port 80 for these network entities,the following user intent statement may be used instead:

-   -   Source: MTV_entities    -   Destination: RTP_entities    -   Action: Drop    -   Protocol: TCP    -   Port: 80

In another example, to disable all incoming connections to networkentities running a Windows 8 operating system, a user can utilize thefollowing user intent statement:

-   -   Source: *    -   Destination: Win8 Filter    -   Action: Drop

In the above user intent statement, “Win_Filter” is the name of aninventory filter that includes “OS==Windows8.”

The example user intent statements above are presented for illustrativepurposes. In some embodiments, user intent statements, inventoryfilters, flow filters, or actions may appear in different formats oreven in a natural language format. For example, FIG. 3 illustrates twoexample inventory filters, in accordance with various embodiments of thesubject technology. The first inventory filter 300 is named “InventoryFilter 1” and is configured to identify all network entities in theinventory store that run on a Linux operating system and have a VRF IDof 676767. The second inventory filter 350 is named “Inventory Filter 2”and is configured to identify all network entities in the inventorystore that represent the 10.0.0.0/8 and 1.1.11.0/24 subnets.

FIG. 4 illustrates an example flow filter incorporating two inventoryfilters, in accordance with various embodiments of the subjecttechnology. The flow filter 400 is configured to identify TCP data flowsbetween the 10.0.0.0/8 and 11.0.0.1 subnets. The flow filter 400 furtheruses two inventory filters 405 and 410 to help identify the subnets.

FIG. 5 shows an example process 500 for managing a network usinginventory filters, in accordance with various embodiments of the subjecttechnology. It should be understood that, for any process discussedherein, there can be additional, fewer, or alternative steps performedin similar or alternative orders, or in parallel, within the scope ofthe various embodiments unless otherwise stated. The process 500 can beperformed by a network, and particularly, a network policy system (e.g.,the network policy platform 110 of FIG. 1 ) or similar system.

At operation 505, the system may generate an inventory store thatincludes records for network entities in the network. The records may becreated or updated based on configuration data received from a networkoperator. The configuration data may include various attributes ofcertain network entities. The attributes may include, for example, aninternet protocol (IP) address, a host name, a geographic location, or adepartment. The configuration data may also include annotations, labels,VPN routing/forwarding (VRF) information, interface information, or anyother data that may be used to identify one or more network entities.

The records may further be created, updated, or supplemented withinformation observed by network agents and reported to the networkpolicy system by the network agents. This information may includeoperating system information, hostnames, interface information, entityidentifiers, policy enforcement information, or data related to entityperformance. Policy enforcement information may include a number ofpolicies being enforced, a number of rules being enforced, a number ofdata packets being allowed, dropped, forwarded, redirected, or copied,or any other data related to the enforcement of network policies. Datarelated to entity performance may include CPU usage, memory usage, anumber of TCP connections, a number of failed connection, applicationsor processes installed or running, disks that are mounted, or other timeseries data.

At operation 510, the system receives a user intent statement thatincludes at least one filter and an action. The user intent statementmay be received from a network operator, application owner, or otheradministrator via a user interface or through another party or servicevia an application program interface (API). The filter may be aninventory filter configured to help identify network entities on whichthe action is to be applied or a flow filter configured to help identifynetwork data flows on which the action is to be applied. The action maybe an enforcement action, a configuration action, or an annotationaction.

The system may query the inventory store to identify network entities towhich the user intent statement applies at operation 515. For example,system may query the inventory store using the one or more filters foundin the user intent statement to identify network entities that match theconditions of the filters. The filters may include one or moreattributes that can be used to narrow down the network entities to onlythose to which the action is to be applied. The attributes may be, forexample, an entity type (e.g., machine, virtual machine, container,process, etc.), an IP subnet, an operating system, or any otherinformation that may be found in the inventory store and used toidentify network entities.

At operation 520, the system generates network policies that apply theaction to the network entities identified by the query. According tosome embodiments, the network policies for user intent statements thatinclude a flow filter or an enforcement action may be implemented in theform of one or more access control lists (ACLs). In some embodiments,network policies for user intent statements that include an annotationaction or configuration action may be implemented in the form ofinstructions to the network entity or a network agent to implement theactions.

The system then enforces the network policies at operation 525.According to some embodiments, some network policies may be enforced onthe system. However, in some embodiments, the system transmits thenetwork policies to one or more network agents configured to implementthe network policies on the network entities.

According to various embodiments of the disclosure, a user or service isable to provide a user intent statement that the system uses to generatemultiple network policies. Accordingly, the user need not spend time andresources explicitly crafting each network policy. Instead, the user mayspecify a reduced number of user intent statements that express theuser's network management desires. Furthermore, the user intentstatements are more understandable to network operators and applicationowners and the system is configured to take the user intent statementsand translate the statements into network policies that network agentsor network entities may use to implement the user's network managementdesires.

In some embodiments, the user intent statements are translated intoplatform independent network policies and stored in the policy store. Toenforce these network policies, the network policy system transmits theplatform independent network policies to network agents running onnetwork entities, where the platform independent network policies areconverted into platform specific network policies and implemented.

FIG. 6 is a conceptual block diagram illustrating an example of anetwork entity 605 that includes a network agent 610, in accordance withvarious embodiments of the subject technology. The network entity 605may be a physical machine (e.g., a server, desktop computer, laptop,tablet, mobile device, set top box, or other physical computingmachine), a virtual machine, a container, an application, or othercomputing unit. A network agent 610 may be installed on the networkentity 605 and may be configured to receive network policies (e.g.,enforcement policies, configuration policies, etc.) from the networkpolicy system 650 via one or more enforcement front end (EFE) modules655.

After an initial installation on a network entity 605, a network agent610 can register with the network policy system 650. According to someembodiments, the network agent 610 may read the Basic Input/OutputSystem (BIOS) universally unique identifier (UUID) of the network entity605, gather other host specific information, and access an agentidentifier for the network agent 610. The network agent 610 generates aregistration request message containing the agent identifier, hostspecific information (including the BIOS UUID) and transmits theregistration request message to an EFE module 655. In some cases (e.g.,when a network agent is just installed), the network agent 610 may nothave an agent identifier. Accordingly, this field in the registrationrequest message may be kept blank until one is assigned.

The EFE module receives the registration request message and, if therequest message contains an agent identifier, the EFE module willvalidate that the BIOS UUID is the same as the BIOS UUID for the entryassociated with the agent identifier in the inventory store. If theinformation matches, the agent identifier in registration request isvalidated and the network agent 610 is registered. The EFE module maygenerate a registration response message with the validated agentidentifier and transmit the registration response message to the networkagent. A BIOS UUID that does not match may indicate that the networkagent's identity has changed. Accordingly, the EFE module may generate anew agent identifier, create an entry in the inventory store for the newagent identifier and transmit the new agent identifier to the networkagent in the registration response message. If the network agentreceives a registration response message that includes an agentidentifier which is different from the agent identifier the networkagent sent in the registration request message, the network agent willupdate its agent identifier and adopt the received agent identifier.

An EFE module 655 may send network policy configuration messages as aseparate message or part of the registration response message. Thenetwork policy configuration messages may contain platform independentnetwork policies to implement on the network entity 605 as well asversion information. The network agent 610 receives a network policyconfiguration message and checks the currently applied policy version.If the policy version for the received network policy configurationmessage is lower than or equal to the applied version, the network agent610 does not need to update the applied policies. If, on the other hand,the policy version is higher than the applied version, the network agent610 will process the received network policy configuration message. Insome embodiments, the network policies in the network policyconfiguration message may be in a platform independent format. Thenetwork agent 610 may convert the platform independent network policiesinto platform specific policies and apply any number of optimizationsbefore applying the network policies to the network entity 605.

The network agent 610 may further be configured to observe and collectdata and report the collected data to the network policy system 650 viathe EFE modules 655. The network agent 610 may collect policyenforcement related data associated with the host entity such as anumber of policies being enforced, a number of rules being enforced, anumber of data packets being allowed, dropped, forwarded, redirected, orcopied, or any other data related to the enforcement of networkpolicies. The network agent 610 may also collect data related to hostentity 605 performance such as CPU usage, memory usage, a number of TCPconnections, a number of failed connection, etc.

According to some embodiments, some of the information collected by thenetwork agent 610 may be obtained by one or more sensors 625 of thenetwork entity 605. The sensors 625 may be physical sensors or logicalsensors and, in some embodiments, may be a part of the network agent 610(e.g., a part of the agent enforcer 615 shown in FIG. 6 ). The networkagent 610 may also collect other data related to the host such as anentity name, operating system, entity interface information, file systeminformation, applications or processes installed or running, or disksthat are mounted. The network agent 610 may collect the information,store the information, and send the information to an EFE module 655from time to time.

According to some embodiments, the network agent 610 may be partitionedinto two or more portions with varying permissions or privileges inorder to provide additional protections to the network entity 605. Forexample, in FIG. 6 , the network agent 610 is shown to include an agentenforcer 615 and an agent controller 620.

The agent controller 620 is associated with an unprivileged status thatdoes not grant the agent controller 620 certain privileges and may beunable to directly access system protected resources. The agentcontroller 620 is configured to communicate with the EFE modules 655 ofthe network policy system 650 via a Secure Sockets Layer (SSL) channeland pass critical data to the agent enforcer via an interprocesscommunication (IPC) channel 630. Interprocess communications (IPC) arecommunication channels provided by an operating system running on thenetwork entity 605 that enable processes running on the network entity605 to communicate and share data.

For example, the agent controller 620 may receive platform independentnetwork policies from one or more EFE modules 655 and pass the networkpolicies to the agent enforcer 615 via the IPC channel 630. The agentcontroller 620 may also receive data collected by the agent enforcer 615(e.g., policy enforcement related data, data related to entityperformance, or other data related to the network entity 605) via theIPC channel 630, generate a message containing the collected data, andtransmit the message to one or more EFE modules 655.

The agent enforcer 615 is associated with a privileged status thatprovides the agent enforcer 615 with additional privileges with respectto the network entity 605. For example, the agent enforcer may directlyaccess or manipulate the network entity's protected resources such as asystem firewall, CPU usage, memory usage, sensors 625, or systeminterfaces. The agent enforcer 615 may be configured to manageregistration of the network agent 610 and select which EFE modules 655with which to communicate. The agent enforcer 615 may further validatenetwork policies received from the network policy system 650 to ensurethat the network policies do not violate any sanity checks or goldenrules (e.g., a network policy that blocks communication from a port thatcommunicates with EFE modules 655 may be ignored) and translate platformindependent network policies received from the network policy system 650to platform specific policies. The agent enforcer 615 may also maintaina policy cache, enforce platform specific network policies, anddetermine whether a network policy has been altered. The agent enforcer615 may also monitors system metrics and policy enforcement metrics sothat the data may periodically be sent to the network policy system 650for analysis.

According to some embodiments, the agent enforcer 615 and the agentcontroller 620 may run independently and the separation of the agentenforcer 615 and the agent controller 620 allow for a more securenetwork agent 610 and network entity 605. For example, the agentenforcer 620 may have no external socket connections in order to reducethe number of vulnerable areas that malicious actors (e.g., hackers) mayattack. Although the agent controller 620 communicates with the networkpolicy system 650 via a SSL channel, damage caused by the corruption ofthe agent controller 620 is limited since the agent controller 620 isunable to directly access privileged resources and cannot enforcearbitrary network policies.

FIG. 7 shows an example process for implementing network policies on anetwork entity, in accordance with various embodiments of the subjecttechnology. It should be understood that, for any process discussedherein, there can be additional, fewer, or alternative steps performedin similar or alternative orders, or in parallel, within the scope ofthe various embodiments unless otherwise stated. The process 700 can beperformed by a network agent (e.g., the network agent 610 of FIG. 6 ) orsimilar system.

At operation 705, an agent controller of the network agent may receive aplatform independent network policy from a network policy system. Theplatform independent network policy may be generated by the networkpolicy system based on, for example, a user intent statement. The agentcontroller may transmit the platform independent network policy to anagent enforcer via an interprocess communication at operation 710. Atoperation 715, the agent enforce may determine implementationcharacteristics of the network entity. The implementationcharacteristics may include, for example, the operating systeminformation of the network entity, port configurations, storageavailable to the network entity, accessories attached to the networkentity, file system information, applications or processes installed orrunning on the network entity, etc.

At operation 720, the agent enforcer may generate one or more platformspecific policies from the platform independent network policy based onthe implementation characteristics and, at operation 725, implement theplatform specific policies on the network entity. Once the platformspecific policies are implemented, the agent enforcer may furthermonitor the network entity to collect data to be reported back to thenetwork policy system or to identify policies that have been altered.

An altered network policy may indicate that a user (e.g., a systemadministrator) or a malicious actor (e.g., a hacker or malicious code)may be trying to change the network policies and a report should be sentto the network policy system for notification purposes. For example, anagent enforcer may identify that a policy in the platform specificpolicies has been altered and revert the altered policy back to aprevious state. The agent enforcer may generate a report detailing thealteration of the network policy and transmit the report, via the IPCchannel, to the agent controller where the agent controller may transmitthe report to the network policy system.

According to some embodiments, the network agent is able to monitor thenetwork entity and collect data to be sent to the network policy systemfor analysis. FIG. 8 shows an example process for providing networkentity reports to a network policy system, in accordance with variousembodiments of the subject technology. It should be understood that, forany process discussed herein, there can be additional, fewer, oralternative steps performed in similar or alternative orders, or inparallel, within the scope of the various embodiments unless otherwisestated. The process 800 can be performed by a network agent (e.g., thenetwork agent 610 of FIG. 6 ) or similar system.

At operation 805, an agent enforcer of a network agent may implement thenetwork policies on the network entity. As described above, the agentenforcer may have a privileged status with respect to the network entityand have permission to take certain actions, access more sensitiveresources, and make privileged system calls. The agent enforcer may alsobe allowed to access certain data that is to be reported to the networkpolicy system at operation 810.

This information may include, for example, policy enforcement dataassociated with the implementation of the network policies on thenetwork entity, system performance data associated with operation of thenetwork entity, or other entity data. The policy enforcement data mayinclude, for example, a number of policies being enforced, a number oftimes each network policy is enforced, a number of data packets beingallowed, dropped, forwarded, redirected, or copied, or any other datarelated to the enforcement of network policies. The performance data mayinclude, for example, central processing unit (CPU) usage, memory usage,a number of inbound and/or outbound connections over time, a number offailed connection, etc. Entity data may include, for example, an agentidentifier, an operating system, a hostname, entity interfaceinformation, file system information, applications or processesinstalled or running, or disks that are mounted. In some embodiments,one or more sensors are configured to collect and store the data and theagent enforcer is able to access the data via an application programminginterface (API) for the sensors.

At operation 815, the agent enforcer may transmit the data to an agentcontroller on the system via an interprocess communication (IPC)channel. The agent controller receives the data and generates a reportthat includes the data at operation 820 and transmits the report to thenetwork policy system at operation 825.

According to various embodiments, the network policy system may use thedata to provide network administrators with reports on a whole networkecosystem and/or individual network entities. The network policy systemmay also use the data to monitor network performance, identify threatsto the network, and/or manage the network policies for the network. Forexample, depending on which policy rules being violated and/or whetherthey are being violated on one, a small group, or across the network,the network policy system may be able to characterize of identify thethreat to the network. Based on historical policy enforcement data, thenetwork policy system may be able to determine whether a threat is newor active.

According to some embodiments, the network policy system may determinethat a policy is never violated based on the policy enforcement data.The larger number of rules increases the computational overhead of thenetwork, the network policy system, and the network entities. Toincrease efficiency, the network policy system may remove the policythat is never violated.

FIG. 9A and FIG. 9B illustrate systems in accordance with variousembodiments. The more appropriate system will be apparent to those ofordinary skill in the art when practicing the various embodiments.Persons of ordinary skill in the art will also readily appreciate thatother systems are possible.

FIG. 9A illustrates an example architecture for a conventional buscomputing system 900 wherein the components of the system are inelectrical communication with each other using a bus 905. The computingsystem 900 can include a processing unit (CPU or processor) 910 and asystem bus 905 that may couple various system components including thesystem memory 915, such as read only memory (ROM) in a storage device920 and random access memory (RAM) 925, to the processor 910. Thecomputing system 900 can include a cache 912 of high-speed memoryconnected directly with, in close proximity to, or integrated as part ofthe processor 910. The computing system 900 can copy data from thememory 915 and/or the storage device 930 to the cache 912 for quickaccess by the processor 910. In this way, the cache 912 can provide aperformance boost that avoids processor delays while waiting for data.These and other modules can control or be configured to control theprocessor 910 to perform various actions. Other system memory 915 may beavailable for use as well. The memory 915 can include multiple differenttypes of memory with different performance characteristics. Theprocessor 910 can include any general purpose processor and a hardwaremodule or software module, such as module 1 932, module 2 934, andmodule 3 936 stored in storage device 930, configured to control theprocessor 910 as well as a special-purpose processor where softwareinstructions are incorporated into the actual processor design. Theprocessor 910 may essentially be a completely self-contained computingsystem, containing multiple cores or processors, a bus, memorycontroller, cache, etc. A multi-core processor may be symmetric orasymmetric.

To enable user interaction with the computing system 900, an inputdevice 945 can represent any number of input mechanisms, such as amicrophone for speech, a touch-protected screen for gesture or graphicalinput, keyboard, mouse, motion input, speech and so forth. An outputdevice 935 can also be one or more of a number of output mechanismsknown to those of skill in the art. In some instances, multimodalsystems can enable a user to provide multiple types of input tocommunicate with the computing system 900. The communications interface940 can govern and manage the user input and system output. There may beno restriction on operating on any particular hardware arrangement andtherefore the basic features here may easily be substituted for improvedhardware or firmware arrangements as they are developed.

Storage device 930 can be a non-volatile memory and can be a hard diskor other types of computer readable media which can store data that areaccessible by a computer, such as magnetic cassettes, flash memorycards, solid state memory devices, digital versatile disks, cartridges,random access memories (RAMs) 925, read only memory (ROM) 920, andhybrids thereof.

The storage device 930 can include software modules 932, 934, 936 forcontrolling the processor 910. Other hardware or software modules arecontemplated. The storage device 930 can be connected to the system bus905. In one aspect, a hardware module that performs a particularfunction can include the software component stored in acomputer-readable medium in connection with the necessary hardwarecomponents, such as the processor 910, bus 905, output device 935, andso forth, to carry out the function.

FIG. 9B illustrates an example architecture for a conventional chipsetcomputing system 950 that can be used in accordance with an embodiment.The computing system 950 can include a processor 955, representative ofany number of physically and/or logically distinct resources capable ofexecuting software, firmware, and hardware configured to performidentified computations. The processor 955 can communicate with achipset 960 that can control input to and output from the processor 955.In this example, the chipset 960 can output information to an outputdevice 965, such as a display, and can read and write information tostorage device 970, which can include magnetic media, and solid statemedia, for example. The chipset 960 can also read data from and writedata to RAM 975. A bridge 980 for interfacing with a variety of userinterface components 985 can be provided for interfacing with thechipset 960. The user interface components 985 can include a keyboard, amicrophone, touch detection and processing circuitry, a pointing device,such as a mouse, and so on. Inputs to the computing system 950 can comefrom any of a variety of sources, machine generated and/or humangenerated.

The chipset 960 can also interface with one or more communicationinterfaces 990 that can have different physical interfaces. Thecommunication interfaces 990 can include interfaces for wired andwireless LANs, for broadband wireless networks, as well as personal areanetworks. Some applications of the methods for generating, displaying,and using the GUI disclosed herein can include receiving ordereddatasets over the physical interface or be generated by the machineitself by processor 955 analyzing data stored in the storage device 970or the RAM 975. Further, the computing system 900 can receive inputsfrom a user via the user interface components 985 and executeappropriate functions, such as browsing functions by interpreting theseinputs using the processor 955.

It will be appreciated that computing systems 900 and 950 can have morethan one processor 910 and 955, respectively, or be part of a group orcluster of computing devices networked together to provide greaterprocessing capability.

For clarity of explanation, in some instances the various embodimentsmay be presented as including individual functional blocks includingfunctional blocks comprising devices, device components, steps orroutines in a method embodied in software, or combinations of hardwareand software.

In some embodiments the computer-readable storage devices, mediums, andmemories can include a cable or wireless signal containing a bit streamand the like. However, when mentioned, non-transitory computer-readablestorage media expressly exclude media such as energy, carrier signals,electromagnetic waves, and signals per se.

Methods according to the above-described examples can be implementedusing computer-executable instructions that are stored or otherwiseavailable from computer readable media. Such instructions can comprise,for example, instructions and data which cause or otherwise configure ageneral purpose computer, special purpose computer, or special purposeprocessing device to perform a certain function or group of functions.Portions of computer resources used can be accessible over a network.The computer executable instructions may be, for example, binaries,intermediate format instructions such as assembly language, firmware, orsource code. Examples of computer-readable media that may be used tostore instructions, information used, and/or information created duringmethods according to described examples include magnetic or opticaldisks, flash memory, USB devices provided with non-volatile memory,networked storage devices, and so on.

Devices implementing methods according to these disclosures can comprisehardware, firmware and/or software, and can take any of a variety ofform factors. Typical examples of such form factors include laptops,smart phones, small form factor personal computers, personal digitalassistants, rackmount devices, standalone devices, and so on.Functionality described herein also can be embodied in peripherals oradd-in cards. Such functionality can also be implemented on a circuitboard among different chips or different processes executing in a singledevice, by way of further example.

The instructions, media for conveying such instructions, computingresources for executing them, and other structures for supporting suchcomputing resources are means for providing the functions described inthese disclosures.

Although a variety of examples and other information was used to explainaspects within the scope of the appended claims, no limitation of theclaims should be implied based on particular features or arrangements insuch examples, as one of ordinary skill would be able to use theseexamples to derive a wide variety of implementations. Further andalthough some subject matter may have been described in languagespecific to examples of structural features and/or method steps, it isto be understood that the subject matter defined in the appended claimsis not necessarily limited to these described features or acts. Forexample, such functionality can be distributed differently or performedin components other than those identified herein. Rather, the describedfeatures and steps are disclosed as examples of components of systemsand methods within the scope of the appended claims.

1. A method comprising: at a network policy system, translating astatement of user intent of a network policy system user with respect toone or more network rules into a network policy; communicating thenetwork policy to a first frontend network policy module incommunication with a first network agent, and to a second frontendnetwork policy module in communication with a second network agent;receiving, at the first network agent, a first policy message sent bythe first frontend network policy module, the first policy messagedescribing an action to take to implement the network policy; receiving,at the second network agent, a second policy message sent by the secondfrontend network policy module, the second policy message describing anaction to take to implement the network policy; implementing, by thefirst network agent, the network policy for a first data flow from afirst network entity, and implementing, by the second network agent, thenetwork policy for a second data flow from a second network entity. 2.The method of claim 1, wherein implementing the network policy for thefirst data flow from the first network entity includes redirecting thefirst data flow.
 3. The method of claim 1, wherein implementing thenetwork policy for the first data flow from the first network entityincludes allowing the first data flow.
 4. The method of claim 1, whereinimplementing the network policy for the first data flow from the firstnetwork entity includes dropping the first data flow.
 5. The method ofclaim 1, wherein implementing the network policy for the first data flowfrom the first network entity includes load balancing the first dataflow.
 6. The method of claim 1, wherein translating the statement ofuser intent associated with the network policy system user with respectto the one or more network rules into the network policy furthercomprises transforming the network policy into a platform-independentformat.
 7. The method of claim 1, wherein one of the first or secondpolicy messages includes a configuration policy.
 8. The method of claim1, wherein one of the first or second policy messages includes anenforcement policy.
 9. The method of claim 1 further comprisingconverting one of the first or second policy messages into aplatform-specific policy.
 10. A non-transitory computer-readable mediumcontaining instructions, which when interpreted by one or moreprocessors on one or more computing hosts in a networked distributedsystem, cause the system to: at a network policy platform, translate astatement of user intent of a network policy system user with respect toone or more network rules into a network policy; communicate the networkpolicy to a first frontend network policy module in communication with afirst network agent, and to a second frontend network policy module incommunication with a second network agent; receive, at the first networkagent, a first policy message sent by the first frontend network policymodule, the first policy message describing an action to take toimplement the network policy; receive, at the second network agent, asecond policy message sent by the second frontend network policy module,the second policy message describing an action to take to implement thenetwork policy; implement, by the first network agent, the networkpolicy for a first data flow from a first network entity, and implement,by the second network agent, the network policy for a second data flowfrom a second network entity.
 11. The computer-readable medium of claim10, wherein implementing the network policy for the first data flow fromthe first network entity includes redirecting the first data flow. 12.The computer-readable medium of claim 10, wherein implementing thenetwork policy for the first data flow from the first network entityincludes allowing the first data flow.
 13. The computer-readable mediumof claim 10, wherein implementing the network policy for the first dataflow from the first network entity includes dropping the first dataflow.
 14. The computer-readable medium of claim 10, wherein implementingthe network policy for the first data flow from the first network entityincludes load balancing the first data flow.
 15. The computer-readablemedium of claim 10, further comprising instructions, which when executedin association with translating the statement of user intent associatedwith the network policy system user with respect to the one or morenetwork rules into the network policy, further cause the system totransform the network policy into a platform-independent format.
 16. Thecomputer-readable medium of claim 10, wherein one of the first or secondpolicy messages includes a configuration policy.
 17. Thecomputer-readable medium of claim 10, wherein one of the first or secondpolicy messages includes an enforcement policy.
 18. Thecomputer-readable medium of claim 10, further comprising instructions,which when executed, cause the system to convert one of the first orsecond policy messages into a platform-specific policy.
 19. A pluralityof hosts, each host including a processor and a memory, arranged into anintent driven network management system comprising: a network policyplatform; a plurality of frontend policy modules in communication withthe network policy platform; a plurality of network agents, wherein eachagent is in communication with a frontend policy module of the pluralityof frontend policy modules; and a plurality of network entities, eachnetwork entity associated with a network agent of the plurality ofnetwork agents, wherein the plurality of network entities send andreceive data flows, wherein the network policy platform is configured totranslate a statement of user intent of an intent driven networkmanagement system user with respect to one or more network rules into anetwork policy, wherein the network policy platform communicates thenetwork policy to a first frontend network policy module of theplurality of frontend policy modules in communication with a firstnetwork agent of the plurality of network agents, and communicates thenetwork policy to a second frontend network policy module of theplurality of frontend policy modules in communication with a secondnetwork agent of the plurality of network agents, wherein the firstnetwork agent is configured to receive a first policy message sent bythe first frontend network policy module, the first policy messagedescribing an action to take to implement the network policy, whereinthe second network agent is configured to receive a second policymessage sent by the second frontend network policy module, the secondpolicy message describing an action to take to implement the networkpolicy, wherein the first network agent implements the network policyfor a first data flow from a first network entity of the plurality ofnetwork entities, and wherein the second network agent implements thenetwork policy for a second data flow from a second network entity ofthe plurality of network entities.
 20. The intent driven networkmanagement system of claim 19, wherein implementing the network policyfor the first data flow from the first network entity includesredirecting the first data flow.
 21. The intent driven networkmanagement system of claim 19, wherein implementing the network policyfor the first data flow from the first network entity includes allowingthe first data flow.
 22. The intent driven network management system ofclaim 19, wherein implementing the network policy for the first dataflow from the first network entity includes dropping the first dataflow.
 23. The intent driven network management system of claim 19,wherein implementing the network policy for the first data flow from thefirst network entity includes load balancing the first data flow. 24.The intent driven network management system of claim 19, wherein thenetwork policy platform is further configured to transform the networkpolicy into a platform-independent format.
 25. The intent driven networkmanagement system of claim 19, wherein one of the first or second policymessages includes a configuration policy.
 26. The intent driven networkmanagement system of claim 19, wherein one of the first or second policymessages includes an enforcement policy.
 27. The intent driven networkmanagement system of claim 19, wherein the first network agent isfurther configured to convert the first policy message into aplatform-specific policy as part of implementing the network policy forthe first data flow.